The Health Insurance Portability and Accountability Act (HIPAA) protects the privacy rights of medical patients by providing guidelines and requirements for access to patient information. For example, HIPAA provides that only specific individuals may access certain information related to particular patients. Caregivers, such as primary care physicians, nurses and others, may be required by HIPAA to have a clinical affiliation with a patient in order to view the patient's information. Some clinical organizations may impose additional constraints on access to patient information.
In some clinical settings, computer systems provide users with access to information related to patients. For example, patient information such as billing, insurance and/or diagnostic information may reside in electronic file storage (e.g., one or more databases) and be accessed using one or more software applications. Some conventional software applications provide functionality which facilitates compliance with HIPAA and/or organizational policies. For example, some software applications request that a user affirm that a clinical affiliation exists between the user and the patient or specify the nature of the affiliation, before allowing the user to view the patient's information. Thus, the user is forced to make an affirmative representation that the access to patient information is in compliance with HIPAA regulations, and a record may be retained for future audits.
Some computer systems which include clinical software applications provide context management capability. As described in co-pending commonly assigned U.S. patent application Ser. No. 09/545,396, Pat. No. 6,993,556, which is incorporated herein by reference, context management capability may be provided via a context manager which can communicate with a plurality of software applications. The context manager may facilitate a sharing of context between applications, wherein the context may include information associated with a user, patient, clinical encounter or other information relevant to the application. As an example, in a system having context management capability, when a user employing a first software application to view information on a patient switches to a second software application to continue work related to that patient, the system may retain a context which automatically identifies the patient and the user to the second application, so that, for example, the user need not provide a user or patient identifier to the second application to begin work. As a result, the user need not perform the time-consuming processes of logging into the second application and providing a patient identifier to access the patient's information. As mentioned above, a context may include any information suitable for sharing between applications.
A standard known as Health Level Seven Context Management Specification was established by the Health Level Seven Clinical Context Object Workgroup (CCOW) to define a standard for an interface and components of a context management system architecture. The standard is referred to hereinafter as “the CCOW standard.” In accordance with the CCOW standard, a context manager facilitates a sharing of context data between applications, wherein context data provides information on various subjects, such as a user, patient, encounter, and others. When a change from one context to another is desired (e.g., when a user wishes to view information on a different patient), a context change transaction is executed, and context data related to one or more subjects may be updated to implement the context change. For example, if a user desires to change the patient for which information is viewed, then a context change transaction may update the patient subject data within a context, but leave other context data (i.e., data on other subjects) intact. For example, the user subject data may be left intact by this context change transaction, so that the user need not log into other applications again to view information on the new patient.
Some context management systems allow user access to patient information (and other information) to be audited, so that compliance with HIPAA, organizational policies and/or other standards may be monitored. For example, a context management system having audit capability is described in co-pending commonly assigned U.S. patent application Ser. No. 10/014,341, Pat. No. 6,941,313 ,which is incorporated herein by reference.
FIG. 1 illustrates an exemplary computer system including a context manager with audit capability, wherein context manager 130 communicates with context-enabled applications 110 and 120 to facilitate context sharing there between. In the system of FIG. 1, applications 110 and 120 both reside on workstation 100, and both may be capable of accessing patient information. Context manager 130 communicates with a storage facility 150 that stores information provided by context manager 130, such as information related to context changes initiated by users of applications 110 and 120. Such information may include an indication of the user who initiated the context change, the patient whose information the user attempted to access, and/or the application employed by the user to initiate the change.
Auditor 140 may extract information from storage facility 150 to determine compliance with HIPAA, organizational policies, and/or other standards. For example, auditor 140 may produce reports which show the patient records that have been accessed by certain users. Auditor 140 may also be configured to produce and send an alert to an administrator if a user who is not authorized to view a particular patient's records attempts to access those records. Other monitoring and/or auditing functions may also be performed.
In certain cases, a user may not be required to have an existing clinical affiliation with a patient to be authorized to view the patient's information. For example, a clinician may need to view a patient's records in an emergency, particularly if the patient's primary caregiver is not available and the patient is in danger. This is commonly referred to in the health care industry as “break the glass” access. In general, a user may break the glass to view patient information if the user is aware that they are not otherwise authorized to access the patient's information, but must to do so to provide proper care for the patient. For example, a clinician may break the glass to determine whether an unconscious patient has any known allergies before administering medication to the patient.